Computer system operators often find that they need to operate their computer systems remotely. For example, telecommuters need to operate their office computer from another location, often from their home. Software exists that allows remote control of a computer system. Such software allows a user to see on a local display terminal the screen the user would see if she were seated before the remote terminal.
A large percentage of today's computer systems run some variant of the Microsoft Windows® operating system. The first version of the operating system to achieve a broad customer base was version 3.1. Much software has been written to operate under Windows 3.1. Since Windows 3.1 is a 16-bit operating system, software designed to run under Windows 3.1 is written as 16-bit code. Windows 3.1 is also a non-preemptive, single-threaded operating system. When a 16-bit program starts running under the Windows 3.1 operating system, it cannot be interrupted by another 16-bit program until the first 16-bit program naturally terminates. This prevents critical segments of 16-bit code from executing simultaneously.
Later versions of Windows include Windows 95 and Windows 98, both of which are 32-bit operating systems. Code written specifically for the Windows 95 or Windows 98 operating systems can take advantage of the 32-bit operating system. Windows 95 and Windows 98 are designed to be backward-compatible, so that 16-bit software will generally operate under the newer versions of the operating system. Specifically, Windows 95 and Windows 98 allow calls to 16-bit Graphical Device Interface (GDI) functions. But because Windows 95 and Windows 98 are preemptive, multi-threaded operating systems, multiple segments of code can execute simultaneously. To prevent multiple critical threads of 16-bit code from executing simultaneously, Windows 95 introduced and Windows 98 retained a mutual exclusion semaphore. This semaphore allows a 16-bit program to specify which segments of code are critical and to “lock” the semaphore, thereby preventing other critical segments of 16-bit code from executing.
But when a 16-bit process is run on a remote 32-bit operating system, a problem can occur. Because the specific GDI functions used by the 16-bit process are themselves written for a 16-bit operating system, the 16-bit program cannot be re-compiled as a 32-bit program. But the software that controls data-flow from the computer to a network in Windows 98 and later versions of Windows 95 and is specially implemented for the 32-bit version of the operating system. (This software is called Winsock 2.) When a 32-bit Winsock function is called from a 16-bit process to transmit data over a network, a “thunk” must be performed. A “thunk” is a transition between the 16-bit program and the 32-bit operating system. A “thunk” occurs when the 16-bit program calls a 32-bit operating system function, or when the 32-bit operating system function returns control to the 16-bit program. One consequence of a “thunk” is that it releases the mutual exclusion semaphore, even though the 16-bit process may not be ready to release the semaphore. When the semaphore is released, other 16-bit programs that generate display data are unblocked and are released to run. This causes ordering problems in the display data.